System and method for transparent single sign-on

ABSTRACT

A method for transparent single sign-on authentication on computers in a networked environment. An embodiment includes receiving an authentication request from an operating system of a first computer, requesting credentials of an application making the authentication request, authenticating the credentials, storing the credentials if the authentication is successful, and transmitting the credentials to a second computer. On subsequent access requests made by the user on the second computer, the credentials can be retrieved from the secure store, eliminating the need to prompt the user to re-enter authentication information.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.11/526,789, filed Sep. 25, 2006, entitled “SYSTEM AND METHOD FORTRANSPARENT SINGLE SIGN-ON”, the entirety of which is incorporatedherein by reference.

TECHNICAL FIELD

The present invention relates generally to a system and a method fornetworked computing environments, and more particularly to a system anda method for single sign-on authentication on computers in a networkedenvironment.

BACKGROUND

Networked computing has increased the functionality of computers byenabling computers that are physically located at different places toshare information as well as applications. A networked computer canaccess applications and data stored on computers that are located faraway, just as if the applications and the data are stored locally. Thiscan increase efficiency since the applications and the data do not needto be installed at each computer, which could mandate a significantincrease in computer management resources to provide necessary support.Furthermore, expenses can be reduced since application licenses do notneed to be purchased for every computer that can potentially make use ofthe applications. Rather, a license that specifies a number ofconcurrently running copies of the application can be purchased and anynumber of computers can then execute the application, as long as thenumber is less than or equal to the licensed number.

With reference to FIG. 1, there is shown a diagram illustrating anexemplary networked computing environment 100. The exemplary networkedcomputing environment 100 includes a first workstation 105 that isoperated by a first user “user 1” and a second workstation 106 that isoperated by a second user “user 2.” The first workstation 105 and thesecond workstation 106 can be connected to a network 110 that permitsthe workstations 105 and 106 to access applications and data stored on adatabase server 115, a first server 120, a second server 125, anotherworkstation 130, and so forth. The workstations 105 and 106 may be inclose proximity to these other computers (located in the same room,building, or campus, for example) or the computers of the networkedcomputing environment 100 may be located in different cities, states,countries, continents, and so forth. While the first workstation 105 isaccessing applications and data stored on one or more of the othercomputers, the second workstation 106 can also be accessing applicationsand data stored on one or more of the same computers. For example, thefirst user on the first workstation 105 can be accessing data via thedata-base 115 while the second user on the second workstation 106 may beauthoring a data-base queries on the data-base 115.

Access to the applications and the data can be controlled byauthenticating users. For example, before a user can launch anapplication, the user's identity may need to be authenticated. This canbe achieved by interrogating the user to provide the requisite accessrequirements, such as account name and password. If the account name andpassword can be verified and the user is on an allowed list of users,then the application can be executed. Unfortunately, the need to enterrepeatedly the access requirements to different applications and/orcomputers can become tedious over the course of a day's work.

In order to simplify the sharing of applications and data in thenetworked computing environment, a technique referred to as singlesign-on (SSO) that requires a user to authenticate only one time persession within a given period of time can be used. As long as the usercontinues to access shared applications and data within a given timeperiod, the user will not be required to authenticate each time newapplications or data are accessed. SSO does not eliminate the need toauthenticate the user, rather, the authentication occurs in thebackground, without requiring user input or intervention.

With reference now to FIG. 2, there is shown a diagram illustrating aprior art technique for implementing SSO in a networked computerenvironment. The diagram shown in FIG. 2 illustrates high-level views ofsoftware present in exemplary computers in the networked computerenvironment. The networked computer environment, as shown in FIG. 2,includes two computers, a first computer 200 and a second computer 250.The two computers are coupled together via a network (not shown). Thefirst computer 200 includes a plurality of applications, such asapplication “app_1” 205 and application “app_N” 206.

The application “app_1” 205 has been modified to support SSO and inconjunction with an SSO plugin 210, which can be a custom designedapplication that is specifically written for the application “app_1” 205and an operating system 220 executing on the first computer 200, usersof the application “app_1” 205 can make use of SSO. The SSO plugin 210can serve as an interface between the application “app_1” 205 and an SSOprovider 215, operating as a bridge between the application “app_1” 205and the SSO provider 215. The SSO provider 215 can provide the necessarysupport for single sign-on on the first computer 200, such as storage ofauthentication information, authorizing users, interfacing multipleapplications, and so forth. The application “app_N” 206 has not beenmodified to support single sign-on, so there is no attendant SSO plugin.Although shown in FIG. 2 as being located in the first computer 200, theSSO provider 215 may be located on a remotely located, centralized host,for example, an SSO host or even on the second computer 250. In general,there is a single logical SSO provider 215 executing within a singlenetworked computing environment.

When a user requests access to an application, such as the firstapplication 205, the SSO plugin 210 can access the SSO provider 215 toauthenticate the user. If the user is already authenticated, then theuser can be permitted to access the application (if the user hasadequate permission to do so). If the user has not been authenticated,then the user will need to authenticate and then access to theapplication can be granted. Although not shown, an SSO token(authentication information) can be passed between applications upon anattempt by a user to launch an application. For example, the SSOprovider 215 can provide the SSO token to the first application 205,permitting the user to launch a second application “APP_2” 207. The SSOtoken may contain important information pertaining to the user as wellas permission level, and so forth, and should therefore be protected toan adequate degree.

An operating system (OS) 220 provides functional control of theoperations of the first computer 200, while a communications (COMM)stack 225 permits the first computer 200 to communicate with othercomputers in the networked computing environment. Different computerscan utilize different operating systems, with examples of operatingsystems being Windows®, Unix, Linux, MacOS®, JAVA®, and so forth. Thesecond computer 250 can contain a set of software applications,operating systems, SSO plugins, and communications stack that may besimilar to or different from the first computer 200.

One disadvantage of the prior art is that an SSO plugin is required forevery combination of application, application to be launched, SSOprovider, and operating system used in the network computingenvironment. This can lead to a large number of different SSO pluginsthat will make support of the network computing environment expensiveand potentially error prone.

Another disadvantage of the prior art is that if an SSO plugin is notavailable for a particular application, SSO provider, and operatingsystem being used, then a different SSO application may be needed, withinteroperability between different SSO applications not ensured.

A primary disadvantage of the prior art is that SSO tokens aretransferred between the various applications, such as the requestingapplication, the application being requested, the SSO provider, the SSOplugin, and so forth. Extensions must be added to each SSO enabledapplication to ensure that the SSO tokens are transferred in a securemanner, particularly between applications on different computers in thenetworked environment.

SUMMARY

These and other problems are generally solved or circumvented, andtechnical advantages are generally achieved, by preferred embodiments ofthe present invention which provides a system and a method fortransparent single sign-on authentication on computers in a networkedenvironment.

In accordance with a preferred embodiment of the present invention, amethod for providing single sign-on to a user of a first computer in anetworked computing environment is provided. The method includesreceiving an authentication request from an operating system of thefirst computer, requesting credentials of an application making theauthentication request, and authenticating the credentials. The methodalso includes storing the credentials and transmitting the credentialsto a second computer, both in response to a successful authentication ofthe credentials.

In accordance with another preferred embodiment of the presentinvention, a network computing device is provided. The network computingdevice includes an operating system that controls interaction betweenusers of the network computing device and applications and data storedin the network computing device, an authentication module coupled to theoperating system, and a single sign-on module coupled to the operatingsystem. The authentication module authenticates credentials of a user ofthe network computing device prior to granting the user access toapplications and data and storing the credentials in a secure storagelocation, wherein once a user's credentials is present in the securestorage location, the user is no longer prompted to re-enter theauthentication information and the single sign-on module transmits theuser's credentials to a remotely located networked computing devicecontaining remotely located applications or data and to verify thevalidity of received credentials.

In accordance with another preferred embodiment of the presentinvention, a networked computing environment is provided. The networkedcomputing environment includes a computer network to convey informationand data, and at least two network computing devices coupled to thenetwork. Each network computing device includes an operating system thatcontrols interaction between users of the network computing device andapplications and data stored in the network computing device, anauthentication module coupled to the operating system, and a singlesign-on module coupled to the operating system. The authenticationmodule authenticates credentials of a user of the network computingdevice prior to granting the user access to applications and data andstoring the credentials in a secure storage location, wherein once auser's credentials is present in the secure storage location, the useris no longer prompted to re-enter the authentication information and thesingle sign-on module transmits the user's credentials to a remotelylocated networked computing device containing remotely locatedapplications or data and to verify the validity of received credentials.

An advantage of a preferred embodiment of the present invention is thatonly a single application is required for each different operatingsystem used in the networked computing environment to provide supportfor SSO with every application requiring authentication in the networkedcomputing environment. If all of the computers in the network computingenvironment use a single operating system, then only a singleapplication needs to be developed and installed on the variouscomputers. Therefore, the costs associated with supporting SSO can besmall and implementation can be rapid.

A further advantage of a preferred embodiment of the present inventionis that since the present invention is an add-on to the operating systemof the computer, regardless of the number of different applicationsexecuting on a computer, only a single application is required tosupport SSO on the computer. The presence of the present invention istransparent to the applications and they continue to operate as before.Therefore, interoperability between applications in the networkedcomputing environment can be readily achieved since the applications donot need to be modified nor do plugins need to be created for eachapplication. Furthermore, the need to develop a single application canreduce the chance of problems and errors occurring.

The foregoing has outlined rather broadly the features and technicaladvantages of the present invention in order that the detaileddescription of the invention that follows may be better understood.Additional features and advantages of the invention will be describedhereinafter which form the subject of the claims of the invention. Itshould be appreciated by those skilled in the art that the conceptionand specific embodiments disclosed may be readily utilized as a basisfor modifying or designing other structures or processes for carryingout the same purposes of the present invention. It should also berealized by those skilled in the art that such equivalent constructionsdo not depart from the spirit and scope of the invention as set forth inthe appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 is a diagram of an exemplary networked computing environment;

FIG. 2 is a diagram of a prior art single sign-on implementation;

FIG. 3 is a sequence diagram of the authentication of a user attemptingto access an application, according to a preferred embodiment of thepresent invention;

FIG. 4 is a diagram of a pair of networked computing devices showing theauthentication of a user attempting to access applications and/or data,according to a preferred embodiment of the present invention; and

FIGS. 5 a through 5 d are diagrams of algorithms supporting singlesign-on in a networked computing environment, according to a preferredembodiment of the present invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The making and using of the presently preferred embodiments arediscussed in detail below. It should be appreciated, however, that thepresent invention provides many applicable inventive concepts that canbe embodied in a wide variety of specific contexts. The specificembodiments discussed are merely illustrative of specific ways to makeand use the invention, and do not limit the scope of the invention.

The present invention will be described with respect to preferredembodiments in a specific context, namely a networked computingenvironment containing computers that will permit authenticated users toaccess applications and data, wherein the users and the applications anddata may be located on a single computer or different computers. Theinvention may also be applied, however, to other multiuser computersystems, such as network appliances connected to a resource network, acomputer connected to a server via a public network (such as an InternetProtocol network), and so forth, wherein there is a desire to enableusers access to applications and data stored anywhere on a network aslong as the users have been authenticated, without forcing the users torepeatedly enter authentication information.

The applications and/or data that a user may wish to access can becategorized into one of two groups based on storage location. Theapplications and/or data can be stored locally or remotely. Locallystored implies that the applications and/or data is resident on someform of storage that is part of the same computer that the user isusing, while remotely stored implies that the applications and/or datais resident on some form of storage on a computer or device that iscoupled to the computer that the user is using by a network connection.

With reference now to FIG. 3, there is shown a sequence diagramillustrating an authentication of a user attempting to access anapplication, wherein the application is locally stored, according to apreferred embodiment of the present invention. The time-space diagramshown in FIG. 3 illustrates the authentication of a user as the userattempts to access two different applications on a computer with SSOsupport provided by an operating system level module. When the userattempts to access a first application 305, an authentication requestcan be generated by the first application 305 and directed to anoperating system (OS) 310 of the computer (the authentication request isshown in FIG. 3 as event 355). At the OS 310, the authentication requestcan be directed by the OS 310 to a service provider interface (SPI)provider 315.

According to a preferred embodiment of the present invention, the SPIprovider 315 can be a specially developed application that can serve asan intermediary between the OS 310 and a SSO provider 320 and handlenecessary operations to support SSO, such as authentication tokenstorage, authentication token verification, authentication tokenretrieval, and so forth. The SPI provider 315 may need to be customizeddepending upon the OS 310 and the SSO provider 320, which can also be anauthentication server, of the computer. For example, for Unix basedcomputer systems, the SPI provider 315 can be created to interfacebetween UNIX Pluggable Authentication Modules (PAM) and a Radiusauthentication server. For other operating systems, different SPIproviders s may be needed for proper interface between the operatingsystem and the SSO provider, such as authentication module SPIs for JavaAuthentication and Authorization Service (JAAS) for JAVA® basedcomputers and Graphical Identification and Authentication (GINA) forWindows® based computers. However, the SPI provider 315 is independentof the applications installed on the computer and a single SPI provider315 can suffice for all installed applications on a single computer.

When the SPI provider 315 receives the authentication request, the SPIprovider 315 can determine if the user's authentication information isstored in a secure storage location (not shown). If the user'sauthentication information is not stored in the secure storage location,then it will be necessary to authenticate the user. This can be achievedby transmitting requests for the user's “user name” and “password” orsome other credentials to the OS 310. These requests are shown as event359 (“user name” request) and event 361 (“password” request). The OS 310can then prompt the user to enter the “user name” and “password” (notshown).

After the user provides the required authentication information, the SPIprovider 315 can make use of the SSO provider 320 to verify the user(event 363). The SSO provider 320 may be executing on the same computeras the SPI provider 315 or it may be executing on a remotely locatedcomputer. When the user has been verified (authenticated), the SSOprovider 320 can return to the SPI provider 315 an authentication tokenfor the user (event 365). The authentication token does not containprecious, secret credential information about the user making itsstorage much more secure than the storage of secret credentials. The SPIprovider 315 can store the authentication token for later use (event367) in a secure storage location, such as a token cache, for subsequentuse. With the successful authentication, the user can be granted accessto the first application 305, although it is possible for the user to besuccessfully authenticated and still not be granted access to anapplication. For example, in a networked computing environment thatimplements access levels, the user may not have adequate accesspermission to access certain applications.

After successfully obtaining access to the first application 305, theuser attempts to access a second application 325. When the user attemptsto access the second application 325, a second authentication requestcan be generated by the second application 325 (event 369) and directedto the OS 310. As with the authentication request generated by the firstapplication 305, at the OS 310, the second authentication request can bedirected to the SPI provider 315 (event 371).

Since the user has previously been authenticated, the SPI provider 315can check in its secure storage location for the authentication tokenand finds the necessary information (event 373).

According to a preferred embodiment of the present invention, safeguardscan be present to help improve the security of the authentication. Forexample, if the user has been idle for an extended period of time, thenthe authentication token may expire and be removed from the securestorage location. If this is the case, then the user may need to bere-authenticated. Even with a valid authentication token, the SPIprovider 315 will need to obtain permission from the SSO provider 320prior to granting the user access to the second application 325 (event375).

Depending upon the implementation of the networked computingenvironment, the user may need to meet other criteria before beinggranted access to the application. For example, the user may need to belisted on a list of allowed users, the user may belong to a group thatis allowed access, and so forth. This can be used to prevent the userfrom accessing applications that require permissions that are greaterthan those assigned to the user. For example, the user may be assigned amedium access level and therefore must be prevented from accessing highaccess level applications and data. With the successful authentication,the user can be granted access to the second application 325. To providean additional level of security, the user may be required to provideadditional authentication information, such as multiple passwords and/orbiometric information (finger prints, retina scans, and so forth). Therequirement of the additional passwords and/or biometric data cansignificantly increase the level of the security of the networkedcomputing environment.

When the applications and/or data are remotely stored, SSO can followroughly the same authentication framework as for the case when theapplications and/or data are locally stored. However, several additionaloperations are needed to share the SSO token that is exchanged betweencomputers over the network connecting the computers and ensure itsvalidity.

With reference now to FIG. 4, there is shown a diagram illustrating apair of networked computing devices showing the authentication of a userattempting to access applications and/or data, wherein the applicationsand/or data are locally stored on a local computer 404 and remotelystored on a remote computer 429, according to a preferred embodiment ofthe present invention. The diagram shown in FIG. 4 illustrates theinteraction between software modules present on the local computer andthe remote computer. The user, making use of a client 405 on the localcomputer 404, initially makes an attempt to access an application and/ordata that is stored on the local computer 404. The access attempt canlead to the generation of an authentication request that can be sent toan operating system (OS) 407 of the local computer 404. The OS 407,after determining that the application and/or the data that the user isattempting to access is locally stored, can forward the authenticationrequest to an SPI provider 409.

The SPI provider 409 can then transmit a verification request to an SSOprovider 411, which may be an authentication server, to authenticate theuser. The SSO provider 411 can be a remotely located computer that isconnected to the local computer 404 by the network, or the SSO provider411 may be located on either the local computer 404 or the remotecomputer 429 (but not both). The SPI provider 409 can also transmit anauthentication token or other restricted credentials provided by the SSOprovider 411 to a secure storage 413. If the authentication request issuccessful, then the user can then be granted access to the applicationand/or data.

The user can also make an attempt to access an application and/or datathat is stored on the remote computer 429. The access attempt can leadto the generation of a request, such as an Internet Protocol request,that can be sent to the OS 407. The OS 407 can send the request to theinter-host transparent SSO (TSSO) 415. Like the SPI provider 409, theTSSO 415 can serve as a bridge between the OS 407 and the remotecomputer 429, providing necessary support for SSO with the remotecomputer 429.

The TSSO 415 can request the user's SSO information from the securestorage 413. After retrieving the user's SSO information from the securestorage 413, the TSSO 415 can make use of the local computer'scommunications stack, for example, an IP stack 417, to transmit theuser's SSO information to the remote computer 429.

At the remote computer 429, a communications stack, such as a second IPstack 420, receives the user's SSO information transmitted by the localcomputer 404. A second TSSO 422 can then receive the user's SSOinformation. The second TSSO 422 can authenticate (verify) the user'sSSO information with the SSO provider 411. A purpose of theauthentication can be to prevent corruption (either intentional orunintentional) of a second secure storage 426 of the remote computer429, for example. After the user's SSO information has been verified,the SSO information can be stored in the second secure storage 426.

To help improve the security of the transmission of the SSO information,computers in the networked computing environment can each contain a listof computers from which they will accept SSO information. If a computerin the networked computing environment receives SSO information from acomputer that is not in its list, then the computer can refuse to act onthe transmission. In another technique to help improve the security ofthe networked computing environment, computers involved in thetransmission of the SSO information may undergo mutual authenticationprior to completing the transmission. A further technique can involvepermitting updates to the secure storage only at specified times. If newSSO information arrives at a computer outside of a specified time, thenthe computer will not act on the transmission.

With the user's SSO information verified and stored on the remotecomputer 429, the processing of the request (the Internet Protocolrequest) can be continued. The processing can continue with the secondTSSO 422 transmitting the request to a second OS 428. The second OS 428then forwards this request to the server 430. The server 430 receivesthe request and knows the client 405 wants to gain access to itsservices or data. The server 430 must authenticate the user of thisclient 405 through a second authentication request. Since the requestedapplication and/or data is stored locally with respect to the remotecomputer 429, the subsequent processing of the second authenticationrequest is similar to the local authentication request discussedpreviously. The server 430 can forward the second authentication requestto the second OS 428.

Since the second authentication request is for access to an applicationand/or data that is locally stored, the second authentication requestcan be provided to a second SPI provider 432. The second SPI provider432 can then retrieve the user's SSO information from the second securestorage 426 and verify the user's authentication state with the SSOprovider 411. If the user has adequate permission for access to theapplication and/or data, the access can be granted. Depending upon theimplementation of the networked computing environment, the user may needto meet other criteria before being granted access to the application.For example, the user may need to be listed on a list of allowed users,the user may belong to a group that is allowed access, the localcomputer may need to be on a list of allowed computers, and so forth.

A preferred embodiment of the present invention comprises the SPIprovider 409 and the TSSO 415, with the SPI provider 409 being used toperform local application and/or data access authentication and the TSSO415 being used to transfer the user's SSO information between the localcomputer 404 and the remote computer 429. Once again, since the SPIprovider 409 and the TSSO 415 are written for a specific operatingsystem, a single implementation of an SPI provider and a TSSO issufficient for each supported operating system in the networkedcomputing environment. Applications installed on a computer do not needto be aware of the presence of the SPI provider 409 or the TSSO 415. Torequest access to applications and/or data, an application only needs toissue a request to the operating system and the processing of the accessrequest can be performed transparently.

With reference now to FIGS. 5 a through 5d, there are shown diagramsillustrating algorithms for supporting SSO in a networked computingenvironment, according to a preferred embodiment of the presentinvention. An algorithm 500 shown in FIG. 5 a illustrates operationsthat can take place in a computer in a networked computing environmentprocessing a request for access to an application and/or data that islocated at the computer, i.e., the application and/or data are locatedlocally. The algorithm 500 can be implemented in an SPI provider, suchas the SPI provider 409 (FIG. 4). The execution of the implementation ofthe algorithm 500 can begin when the SPI provider 409 receives anauthentication request from an OS (block 505), such as the OS 407. Theauthentication request can be generated as a part of a request by a userat the computer for access to an application and/or data that is locatedat the computer. For example, the user may double-click on an iconrepresenting an application in an attempt to launch the application. Theauthentication request from the OS 407 can contain information, such asthe application and/or data that the user wishes to access, userinformation, and so forth. The SPI provider 409 can then check in asecure storage, such as the secure storage 413, to determine if theuser's SSO information is stored in the secure storage 413 (block 507).

If the user's SSO information is not stored in the secure storage 413,then the SPI provider 409 can request the user to enter the neededauthentication information (block 508) by transmitting an authenticationrequest to the OS 407. The OS 407 can then prompt the user to entertheir “user name” and “password,” for example. As the user enters theneeded authentication information, the user's identity will need to beauthenticated (block 509). After the user's identity has beenauthenticated, the SPI provider 409 can check to determine if the userhas adequate permission to access the requested application and/or data(block 511). The permission check can be made with an authenticationserver, such as the SSO provider 411.

If the SSO provider 411 determines that the user has sufficientpermission to access the requested application and/or data, the SSOprovider 411 can return an authentication token, which can contain SSOinformation, that can be received by the SPI provider 409 (block 513).The SPI provider 409 can save the user's authentication token in thesecure storage 413 and the user can be allowed to access the applicationand/or data.

If the user's SSO information is stored in the secure storage 413 (block507), then the SPI provider 409 can retrieve the user's SSO information,typically in the form of an authentication token, from the securestorage 413. Even with the authentication token, the SPI provider 409must verify the token's validity (block 518) and may still need check todetermine if the user has adequate permission to access the requestedapplication and/or data (block 519). Although the user's authenticationtoken was found in the secure storage 413, the check of the user'spermission level is still required to ensure that the user is notgranted access to applications and/or data that requires a higherpermission level. If the user has adequate permission to access theapplication and/or data, then the user can be allowed to access theapplication and/or data.

Algorithms shown in FIG. 5 b (algorithm 525), FIG. 5 c (algorithm 540),and FIG. 5 d (algorithm 550) illustrate operations that can take placein computers in a network computing environment processing a request foraccess to an application and/or data that is remotely located from acomputer that is being used by a user making the request for access,with the algorithm 525 shown in FIG. 5 b illustrating operations thatcan take place at the remote computer being used by the user (clientside) and the algorithms 540 and 550 shown in FIGS. 5 c and 5 dillustrate operations that can take place at the remote computercontaining the application and/or data (server side).

The algorithm 525 shown in FIG. 5 b illustrates operations that can takeplace in a local computer being used by a user making a request foraccess to an application and/or data stored on a remote computer,according to a preferred embodiment of the present invention. Thealgorithm 525 can be implemented in a TSSO, such as the TSSO 415 (FIG.4). The execution of the implementation of the algorithm 525 can beginwhen the TSSO 415 receives an remote connect request from the OS 407, inthe form of a packet send (block 530). After the TSSO 415 receives thepacket the TSSO 415 can access the secure storage 413 to retrieve theuser's SSO information, typically in the form of the user'sauthentication token (block 532). If the user's authenticationinformation is not in the secure storage 413, then it will be necessaryto authenticate the user's identity in a manner similar to that describepreviously in the discussion of FIG. 5 a. After obtaining the user's SSOinformation, the TSSO 415 can transmit the user's SSO information to theremote computer via a communications stack, such as the IP stack 417(block 534) and then send the packet (block 536). In an alternateembodiment, it is possible to skip the transmission of the SSOinformation (block 534) if the SSO information has been previouslytransmitted to the specific remote OS within a given time period.

The algorithm 540 shown in FIG. 5 c illustrates operations that can takeplace in the remote computer that contains an application and/or datathat is requested by the user on the local computer, when the remotecomputer first receives the transmission, according to a preferredembodiment of the present invention. The algorithm 540 can beimplemented in a TSSO in the remote computer, such as the second TSSO422 (FIG. 4). The execution of the implementation of the algorithm 540can begin when the second TSSO 422 receives the user's SSO informationtransmitted by the local computer (block 542). To prevent contaminationof SSO information, the second TSSO 422 can verify the user's SSOinformation using an authentication server, such as the SSO provider 411(FIG. 4) (block 544). For example, without verification, it is possibleto maliciously provide forged user SSO information to the remotecomputer, which would then result in the forged user SSO informationbeing stored in a secure storage, such as the second secure storage 426,of the remote computer. After the second TSSO 422 verifies the user'sSSO information, the second TSSO 422 can store the user's SSOinformation in the remote computer's secure storage, such as the secondsecure storage 426 (FIG. 4) (block 546).

The algorithm 550 shown in FIG. 5 d illustrates operations that can takeplace in the remote computer that contains an application and/or datathat is requested by the user on the local computer, wherein the remotecomputer has already received the user's SSO information, according to apreferred embodiment of the present invention. After the second TSSO 422verifies the user's SSO information (block 544) and stores the SSOinformation in the second secure storage 426 (block 546), the first TSSO415 can forward the packet to an OS of the remote computer, such as thesecond OS 428 (FIG. 4), which forwards the packet to a server, such asthe second server 430 (FIG. 4), of the remote computer (block 552). Thesecond server 430 then makes an authentication request to the second OS428 to authenticate the user of the client (block 554).

The processing of the authentication request can be completed by the SPIprovider 432 of the remote computer. The SPI provider 432 can receivethe authentication request from the second OS 428 (block 556). The SPIprovider 432 can then retrieve the user's SSO information (block 558)and verify the authentication request (block 560) utilizing processingthat is similar to the processing illustrated in algorithm 500, shown inFIG. 5 a. With the authentication request verified, the access to theapplication and/or data can be allowed.

Although the present invention and its advantages have been described indetail, it should be understood that various changes, substitutions andalterations can be made herein without departing from the spirit andscope of the invention as defined by the appended claims.

Moreover, the scope of the present application is not intended to belimited to the particular embodiments of the process, machine,manufacture, composition of matter, means, methods and steps describedin the specification. As one of ordinary skill in the art will readilyappreciate from the disclosure of the present invention, processes,machines, manufacture, compositions of matter, means, methods, or steps,presently existing or later to be developed, that perform substantiallythe same function or achieve substantially the same result as thecorresponding embodiments described herein may be utilized according tothe present invention. Accordingly, the appended claims are intended toinclude within their scope such processes, machines, manufacture,compositions of matter, means, methods, or steps.

What is claimed is:
 1. A method of providing single sign-on service to auser of a user computing device, the method comprising: providing anoperating system on the user computing device, the operating systemconfigured between a plurality of applications on the user computingdevice and a single sign-on provider; receiving in the operating systemrespective authentication requests from the plurality of applications;and forwarding authentication requests corresponding to the receivedauthentication requests from the operating system to the single sign-onprovider.
 2. The method of claim 1, further comprising providing asingle sign-on provider interface between the operating system and thesingle sign-on provider, wherein forwarding authentication requestscorresponding to the received authentication requests from the operatingsystem to the single sign-on provider comprises forwarding thecorresponding authentication requests via the single sign-on providerinterface.
 3. The method of claim 2, wherein receiving in the operatingsystem respective authentication requests from the plurality ofapplications and forwarding corresponding authentication requestscorresponding to the received authentication requests comprises:receiving in the operating system, from a first application controlledby the operating system, a first authentication request from the user;receiving user credentials from the user; requesting access for thefirst application using the received credentials via the single sign-onprovider interface; receiving a user token associated with the user viathe single sign-on provider interface; storing the user token associatedwith the user; receiving in the operating system, from a secondapplication controlled by the operating system, a second authenticationrequest from the user; retrieving the stored user token; and requestingaccess for the second application using the retrieved user token via thesingle sign-on provider interface.
 4. The method of claim 3, furthercomprising: in response to the first authentication request from theuser, determining that a user token associated with the user has not yetbeen stored; and in response to determining that a user token associatedwith the user has not yet been stored, prompting the user to provideuser credentials.
 5. The method of claim 4, wherein the single sign-onprovider interface: determines that a user token associated with theuser has not yet been stored; prompts the user to provide usercredentials via the operating system; receives the user credentials viathe operating system; forwards the received credentials to the singlesign-on function; and receives and stores the user token associated withthe user.
 6. The method of claim 3, wherein retrieving the stored tokenis responsive to determining that a user token associated with the userhas been stored.
 7. The method of claim 3, comprising verifying theretrieved user token before requesting access for the second applicationusing the retrieved token.
 8. The method of claim 7, whereinverification of the retrieved user token comprises determining whetherthe user has been idle for a predetermined length of time.
 9. The methodof claim 7, wherein the single sign-on provider interface verifies theretrieved user token.
 10. The method of claim 3, further comprisingremoving the user token from storage when the user is idle for apredetermined length of time.
 11. The method of claim 3, wherein thesingle sign-on provider interface: interface determines that a usertoken associated with the user has been stored; retrieves the storeduser token; and requests access for the second application using theretrieved user token.
 12. The method of claim 1, wherein the singlesign-on provider is implemented on a network server coupled to the usercomputing device.
 13. The method of claim 12, wherein the network serveris an authentication server.
 14. The method of claim 1, wherein thesingle sign-on provider is implemented on the user computing device. 15.The method of claim 1, further comprising providing an inter-host singlesign-on interface on the user computing device between the operatingsystem and a remote computing device, wherein forwarding authenticationrequests corresponding to the received authentication requests from theoperating system to the single sign-on provider comprises forwarding atleast one corresponding authentication request via the inter-host singlesign-on interface to the remote computing device to request access to atleast one application running on the remote computing device.
 16. Themethod of claim 15, further comprising maintaining, in the remotecomputing device, a list of networked computing devices from which theremote computing device will accept authentication requests.
 17. Themethod of claim 15, wherein the remote computing device has aninter-host single sign-on interface coupled to the inter-host singlesign-on interface of the user computing device, the method furthercomprising: receiving at the inter-host single sign-on interface of theremote computing device an authentication request from the inter-hostsingle sign-on interface of the user computing device, an authenticationrequest comprising a user token; and verifying the received user token.18. The method of claim 17, wherein verifying the received user tokencomprises verifying the received user token by comparison with a usertoken stored at the remote computing device.
 19. The method of claim 17,wherein verifying the received user token comprises verifying thereceived user token by comparison with a user token stored at the singlesign-on provider.
 20. The method of claim 17, further comprising storingthe verified user token at the remote computing device.
 21. The methodof claim 17, further comprising providing access of the user computingdevice to the requested at least one application running on the remotecomputing device after verifying the user token at the remote computingdevice.